斩获BAT技术专家Offer，他到底经历了什么？

“

之前写过《互联网公司的面试官是如何 360° 无死角考察候选人的？》，通过这篇文章，我们给大家聊了聊国内中大型互联网公司，在 Java 面试时一些高频的技术问题。

本文我们通过一篇真实的一线面经，带大家去体验一下 BAT 等互联网公司的面试现场氛围！

面试者是笔者以前的下属，多年的好朋友。这是他去年早些时候出去面试，拿到 BAT 等多家一线互联网公司技术专家 Offer 的面试经历。

先介绍一下这位朋友的个人经历：

• 本科毕业，接近 10 年工作经验。跳槽之前，在国内某大型互联网公司里带一个 8 人左右的技术团队。

• 由于公司业务发展较为平缓，所以职业上升机会较少。

• 朋友对其负责的系统架构和技术已经非常熟悉，薪资上也较难有大幅度的增长，至于晋升更高的级别，短期内也不容易。

因此，在仔细思考一番之后，决定出来看看机会，能否在带团队的规模、技术以及薪资上实现一个突破。

一面

一面是一个猎头给朋友推的一个职位，BAT 中某一个大厂的某个团队，具体就不说是哪个部门了。

一面就直接过去当面聊了一次，大概从下午 2 点聊到了下午 4 点多，时间很长，炮火相当猛烈。

一面面试官也是专家职级，上来就是先聊项目，针对项目中的各种细节仔细问，就项目展开，而且极其注重细节。

下面的内容，是根据朋友面试之后的回忆，整理出的部分问题：

面试同样是通过互联网公司最喜欢的连环炮形式发问。比如在面试过程中，聊到了缓存，连环炮如下。接着，面试官继续深扣了很多细节。

面试官：

• 那请说一下，这些请求具体是落在哪些接口上？

• 哪些数据是数据库和缓存双写一份的？

• 双写一致性如何保证？保证一致性的同时如何保证高并发和性能？

• 缓存线上是如何部署的？给了多大的总内存？命中率有多高？

• 缓存抗了多少 QPS？数据流回源会有多少 QPS？

• 是否某个 key 出现了热点缓存导致缓存集群中某个机器的负载过高？如何解决的？

• 是否出现超大 value 打满网卡的问题？如何规避这个问题？

• 线上是否出过缓存集群事故？如果出现了你们怎么解决有什么高可用保障预案？

• 平时如何监控缓存集群的 QPS 和容量？如果要扩容该怎么扩？能否平滑扩容？扩容会导致系统需要停机吗？

• 聊聊 Redis 的集群原理？扩容的时候会不会导致数据丢失？key 寻址算法都了解哪些？

• 你了解一致性 hash 算法吗？画个图说说 Redis 线程模型和内存模型？

朋友：纸笔翻飞，大脑高度运转，一个接一个的回答。。。

如上所述，所有问题，全部结合项目，落地到生产中，同时注重聊技术的很多细节，包括技术的一些原理。

像缓存这样的连环炮提问法，面试官还用来问了 MQ、MySQL 分库分表、高可用、JVM、多线程并发，等各种问题。

简单总结：

• 一面其实关注了技术广度，同时结合项目死扣各种细节。

• 另外也兼顾了一定的技术深度，会就一个技术往深了问下去。

总体来说，一面还算顺利，毕竟都是结合项目来问的，各种细节平时朋友进行架构设计时，都会仔细考虑过。

而且朋友也做过线上的高并发系统，踩过很多坑，所以这些问题基本都回答的不错。

但是这里给大家提醒一句，一般某个同学出去面试，回来之后其他人问他面试经验，一般都是问：都有啥面试题？面试官是怎么问的？

说实话，大家看了上面那些问题，可能会觉得说，哦，其实我也可以答出来，没什么特别的。

但其实并不是这样，如果只是拿高级岗位的 Offer，你的技术会占很大比重。

但是如果要拿专家岗位的 Offer，你到底有没有线上真实的高负载的系统架构经验，非常重要。

同样的问题，普通人会回答的很普通，但是经历过真实几十亿流量请求的人一定会说出大量经验总结、教训以及踩坑。

而且对整套复杂的大型系统到底是如何抗住高并发的，会了然于胸，熟悉所有的细节。

所以针对一面，一般就是结合项目，深挖细扣，看你到底有多少水平，做过多复杂的系统。

这块说实话，做过就是做过，没做过就是没做过，是不可能作假的。很多同学可能自己平时也看过很多书和博客，但是看书和博客只是基础，如果没有真实的线上生产环境的历练，是肯定不够的。毕竟实践出真知！

二面

一面就顺利通过了，紧接着安排了第二轮面试。二面面试官应该是这个团队的 Leader，P8 级别的，如果进去，应该就是朋友未来的顶头上司。

据朋友讲，二面面试官态度非常好，很和蔼，看来一面面试官反馈之后，这个 Team 对朋友还是比较重视的。

技术深度

二面内容就从广度变成深度了，面试官技术实力很深厚，应该是有十几年经验。对相关技术深挖了很多东西。

同样，二面也聊到了缓存相关的问题。问了朋友具体了解过哪些缓存技术，Redis、Memcached，还有阿里开源的 Tair，哪个了解过内核原理？

朋友之前看过一些 Redis 的内核，就聊了聊 Redis 内核的一些数据结构和实现原理。包括集群、持久化在内核层面的一些东西。

此外在 MQ 这块，朋友正好对 Kafka 做过深入的研究，就聊了聊 Kafka 的源码。

比如 Kafka Controller 在故障转移这块的源码，日志存储、网络通信的一些细节。

如何保证磁盘读写的高性能，零拷贝那块的底层实现，leader 和 follower 之间的数据是如何同步的，都是从源码层面来聊。

此外，还聊了 Dubbo 的源码以及 MySQL 内核层面的东西。

系统设计、工程素养、带团队

同时二面非常重视考察系统设计能力、工程素养、带团队的能力。比如面试官就这个部门负责的一块业务，出了一个相关的系统设计题目。

题目细节记不清楚了，大体内容是给出具体的用户量、业务场景、并发量、数据量，然后让你整体负责这个系统的架构设计。

朋友需要阐述自己的整体设计思路，从哪些点来考虑，存在着哪些技术挑战，并且现场画出来具体的架构设计图。

工程素养这块，让朋友聊了聊平时如何做的技术设计、技术评审、编码规范、测试、上线、回滚、灰度、压测、监控等等。

带团队，让朋友说一下，如何招人、面试标准、如何搭建团队的人才梯度，等等。

架构演进

此外，还会问一下，整个系统架构是如何一步一步进行演进的。从 0 到 1 的时候是什么架构？从 1 到 10 的时候是什么架构？从 10 到 100 的时候是什么架构？这块就是看看你的整体架构能力，以及技术规划能力。

说到这里，笔者提一句，如果出去面试，尤其是去 BAT 等大型互联网公司面试，必须精心准备。

包括你的项目的每个细节，你解决过的各种线上问题和坑，你简历里的技术是否达到一定的深度，你平时其他的工程、设计能力，这些都一定要精心准备一下。

绝对不要裸面！绝对不要裸面！绝对不要裸面！重要的事情说三遍！裸面必败，而且如果一问三不知，那么给人的印象就是很差的。

如果要冲着心仪的大公司去，最起码精心准备 1 个月以上，大家务必记住这一点，这也是朋友这次的一个重要心得，准备充分了，才能有备无患。

三面

二面之后，又等了大概一两周。。。因为越往上面，领导级别越高，平时越忙，有时人家可能出差开会去了，不过等了一两周，那边总算约上了三面。

三面是总监级别的，不太确定是走的 M 线还是 P 线。如果是 P 线，那么一定是 P9，但是观察面试风格应该是 M 线的总监。

这一面，聊技术其实并不多，更多的是跟朋友聊过往的各种公司的经历和项目经验，具体负责过哪些比较有挑战的大型的系统。

另外，考察了各种软素质。比如说责任心、抗压能力、自我驱动，让朋友举例说明自己过去的一些事情，来证明软素质。

同时还会聊聊职业价值观，是否愿意加班，等等吧。最后也聊了聊朋友的职场期望，包括这个团队是干什么的，未来的发展方向之类的。

朋友觉得最重要的还是前面两面，其实这一面，只要人品端正，平时干活儿认真负责，一般的都没什么太大的问题。

终面

接着又过了一两个礼拜，因为当时二面面试官，也就是那个未来可能成为朋友 Leader 的人，对朋友还是比较看重的，私下还短信联系了一段时间，就怕朋友跑去别的公司了。

他告诉朋友说是因为 HR 那边太忙了，所以终面还未安排上。关于 HR 面，朋友印象真是相当之深刻，为什么呢？

因为 HR 是直接电话聊的，没过去了，过去实在太折腾，而且二面面试官也是去打了招呼。

HR 当时居然是晚上 11 点打来的电话，人家刚刚加班开会结束，就打来了电话，真是不得不佩服其敬业精神！

而且这位 HR 是相当专业的，如果是普通的 HR 其实随便聊聊就行了，但是这边的 HR 问了很多问题，大概聊了 1 个小时左右。

主要是跟朋友聊了一些价值观的东西，比如之前觉得做过最难的事情是啥，怎么克服的，当时啥心态。

还有就是为啥要离职，没有发展空间？那当时没考虑过公司内部 transfer（转岗）吗？为啥不好 transfer？你的绩效平时怎么样？你觉得你跟同事相处的怎么样？

终面内容，总结起来，其实还是一句话，你人品正就好了，一般都问题不大，老老实实的踏实回答。

后来 HR 面了过后，那边的薪资确实给到位了，达到了朋友的期望薪资。但是那边给的规划是未来可以带的团队人数也就是 10 人以内，而且不是配发集团股票，是配发的正在快速发展的这个团队的期权。

所以朋友当时纠结了一下，但还是先答应了，于是 Offer 就发了过来。

后记

本来朋友想的是，如果没有别的更好的机会，那么这个机会也可以考虑，毕竟薪资上还是可以的。

但是当时包括 TMD（头条、美团、滴滴）这边，也都有人内推朋友过去试试，所以当时也面了其他的几个一线互联网公司。

其实如果经历了 BAT 这种互联网公司的几轮技术面试洗礼，那么去国内任何一个公司都没什么问题了，所以当时面试也都很顺利，驾轻就熟。

同样，朋友也不出意外的拿到了那些一线互联网公司的 Offer。经过一番对比，朋友最终没有选择去最初面试的那个 BAT 中的某个大厂，而是去了上面说的那几个超级独角兽公司中的其中一个。

原因是这家超级独角兽公司给出的薪资超出期望之外，而且领导对朋友同样非常重视，配发了大量的期权，承诺可以独立带 20+ 人的团队。

而朋友更看重的是这个超级独角兽公司未来的潜力：

• 公司发展速度快，人员扩张迅猛，所以给到的带团队的机会非常好，能带更大的团队，比朋友当前带的团队规模大了一倍多。

• 虽然 BAT 的那家大厂同样配发了期权，但是这家超级独角兽的期权未来潜力可能更大。事实证明，的确如此。

所以综合考虑了之后，朋友最终还是根据自己的职业发展选择了独角兽公司，没有再回到 BAT 行列中。

作者：中华石杉

编辑：陶家龙、孙淑娟

出处：转载自微信公众号：石杉的架构笔记（ID：shishan100）

中华石杉：十余年 BAT 架构经验，一线互联网公司技术总监。带领上百人团队开发过多个亿级流量高并发系统。现将多年工作中积累下的研究手稿、经验总结整理成文，倾囊相授。微信公众号：石杉的架构笔记（ID：shishan100）。

精彩文章推荐：